為了能讓在不同行程空間的軟件溝通，Android 提供了 Binder System 作 IPC。我們在此剖析 Android如何透過 Binder System 達到 跨行程空間的軟件溝通。
我也介紹在 Android 框架常見的 設計樣式，例如 Template method。

所有文章
http://ithelp.ithome.com.tw/category/家庭雲
下圖是在這專案的 AndroidManifest.xml ，從這看出我們需要一個Activity來提供UI 介面，此外還需一個remote Service，負責存取Zigbee 裝置的狀態。

Activity提供UI 介面，讓使用者在客廳時，能透過藍芽鍵盤、遙控器或滑鼠，直接操作，畫面如下圖。

而remote Service與上述的Activity 有各自的行程空間，雙方無法直接溝通。倘若，UI 所在的Activity，想跨行程的呼叫Remote Service的函式，該如何做呢 ?

目前智慧型手機已經相當普及，所以在 APP 的設計上也須考量安全性。下圖的架構設計，也考量到安全性。 Activity 與 Service ，執行於不同的行程空間，各有自己的UID (Linux User Id)與 PID (Linux Process Id)。Service 可經由取得 Context物件參考，呼叫 checkpermission(String permission, int pid, int uid), 作權限的檢查。當Service 確認提供服務時，再來看服務是如何提供給另一行程的 Activity。

進一步剖析設計前，先來介紹一個在Android框架常見的設計樣式 – Template Method。

上圖中的Binder Class 定義一個transact() 函式，他會呼叫 在相同類別內的onTranact()，還記得之前介紹的onKey()卡榫函式嗎 ? 這onTransact()也是一個卡榫函式。
Binder 是抽象類別，我們的myJigbeeAdapter繼承 Binder，因此，myJigbeeAdapter
須提供OnTransact()的程式實作。 當圖中的 Activity Class ac01 取得iBinder的參考後，會呼叫 transact()，而依Template Method 設計樣式，這transact()會呼叫 Binder的 onTransact()，因為Binder的onTransact()是抽象函式，所以會自動呼叫其子類的onTransact()。這就是 IoC(Inversion of Control 反向呼叫)，這是框架 最具威力所在。
框架對 AP 的掌控權也來自於此，子類繼承具有抽象函式的父類，而必須實作父類的抽象函式，父類會呼叫子類實作的這個函式，等於是父類下命令，交由子類執行。父類是虛類，子類是實類，虛實相依了，卡榫接合。

請注意 transact 前有 + 號，代表它是公開的，這也是 IBinder這個介面所定義的。
誰取得這個 IBinder ，誰就能使用IBinder。 問題是在相同行程是如此，跨行程就行不通了。為何? 因為在不同行程空間，兩造是互不相識的。那怎麼辦 ? 所幸，Android 提供了 Binder System 的 IPC通訊機制。 幫忙兩造作溝通，請看下圖，架構設計。我也列出程式主要之實作部分供參考。

-- 待續...

所有文章
http://ithelp.ithome.com.tw/category/家庭雲